IBIS Macromodel Task Group

Meeting date: 17 September 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Altair:                     * Junesang Lee
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:                Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Dassault Systemes:            Longfei Bai
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
                              Sai Zhou
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                            * Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Samsung:                      Jun-Bae Kim
Siemens EDA (Mentor):       * Arpad Muranyi
                              Randy Wolff
Signal Edge Solutions       * Benjamin Dannan
Teraspeed Labs:               [Bob Ross]
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Junesang (Jaden) Lee introduced himself to the group.  He joined the mailing
  list several years ago, and he is working on creating IBIS AMI solutions for
  Altair.

-------------
Review of ARs:

Yifan:  Send her "IBIS SPICE validation" presentation slides to ATM.
        - Done.

Yifan:  Prepare a new draft of BIRD220.1 with a description of the limitation of
        the algorithm.
        - Done.

Michael:  Send out an updated Ts4file proposal containing changes discussed in
          the meeting.
          - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the September 10th
meeting.  Michael moved to approve the minutes.  Jared seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD220.1 update:
Yifan said that she had sent out an updated draft of BIRD220.1.  She asked
whether anyone had any feedback or if the draft was ready for the Open Forum.
Arpad recalled the SPICE driver model containing separate pre-driver paths for
the pullup and pulldown transistors, which he had previously provided Yifan for
testing.  He reviewed a set of rising and falling transitions he had previously
generated with the SPICE model driving a resistive load into various V_fixture
values.  He noted that the rising edges for values of V_fixture between Vss
and Vdd showed a plateau in the middle of the transition at the V_fixture value.
He said the plateau was the period when neither transistor was active, as the
transistor turning off is shut off before the other transistor is turned on, to
minimize crowbar currents.  He asked whether the presence of the plateau might
indicate to the model maker when a device is not suitable for application of
BIRD220.1.  However, he noted that the falling edges showed significantly
smaller plateaus, so he wasn't sure this technique would work.  Is it really
just a question of pre-driver timing that alone determines whether BIRD220.1
will work?  Yifan agreed to investigate and provide an update.

Ts4file and [Ramp]:
Michael recalled that the previous meeting's discussion had ranged widely and
covered topics such as whether [Ramp] should still be required in all cases, the
language in the specification describing the purpose of [Ramp], and whether
[Ramp] data must be consistent with any non-traditional model information such
as Ts4file and [External Model].

Michael asked whether we want to maintain [Ramp] as a required keyword, even for
non-traditional models (e.g., models using Ts4file or [External Model]).  He
asked whether [Ramp] has much utility in the context of non-traditional models.
He recalled Ambrish's comment that we essentially reinvented the definition of
[Ramp] when it is used with [External Model] (IBIS 7.2, pg. 136):
  ...within the scope of [External Model], the [Ramp] keyword is intended
  strictly to provide EDA tools with a quick first-order estimate of driver
  switching characteristics.
Michael said any new language about [Ramp] in the context of Ts4file should
follow that precedent.

Michael said that if we decide [Ramp] is no longer required, then many of our
issues with language and checking go away.  If, however, we continue to say
[Ramp] is required, then how do we make sure it's valid and define what has
to match with other data in the model?  Arpad recalled that at the previous
meeting he, Walter and others had agreed that the keyword itself should still
be required.  However, there was no agreement to require the [Ramp] data to
match Ts4file, [External Model], etc.  Arpad said he had sent an email with some
new thoughts on this topic.  He proposed that we extend the language used in
[External Model] to Ts4file and traditional I-V and V-t table models.  He said
that [Ramp] is the primary source of information only when nothing else
exists (i.e., a model with no I-V tables, no Ts4file, no [External Model]).
Fangyi provided a counterexample.  What if a model includes only Ts4file and
[Ramp]?  In that case, the [Ramp] is the only source of data for a non-AMI
simulation.  Arpad said the question is whether the Ts4file can be used in a
non-AMI simulation.  Fangyi noted that the specification currently says Ts4file
is "exclusively limited to AMI applications" (IBIS 7.2, pg. 316).  Arpad
acknowledged the language, but said it's still an open question.  Walter said
the language does not forbid an EDA tool from using Ts4file in any context.

Arpad asked, for a normal non-AMI simulation, are we allowed to use the Ts4file?
Walter said that if I-V tables were also included in the model, then he would
use those in a non-AMI simulation.  However, if Ts4file was the only thing other
than [Ramp], then he would use the Ts4file data.  It's up to the tool or user to
decide which to use, but a model that only has [Ramp] isn't very useful.  Arpad
said we might need to change the "exclusively limited to AMI applications"
language if everyone agrees with Walter's interpretation.

Walter said that I-V and V-t tables, [External Model], and Ts4file are three
independent representations of a model's data.  The only thing they have in
common is that [Ramp] is intended to provide a first order estimate of band-
width information in all three cases.  Walter said the parser should continue
checking [Ramp] vs. static I-V table data (if it's provided), but [Ramp] should
not be checked against Ts4file or [External Model].  He said for Ts4file and
[External Model] the dt portion of [Ramp] provides a bandwidth estimate, and
we need not check it.

Arpad noted that even for I-V and V-t models the parser only checks the dV
portion of the [Ramp] against what would be expected hooking the I-V tables up
to the same load.  He said the [Ramp] dt can't really be checked against the
V-t waveforms anyway.  He noted that we typically have two rising waveforms,
for example, with one for a load to Vcc and one for a load to ground.  He said
one of those waveforms is likely dominated by the pulldown turning off, and the
other is dominated by the pullup turning on.  So, a single [Ramp] dt value
likely can't match both of them.

Michael said that if we're willing to allow I-V and V-t data to be completely
independent of Ts4file and not subject to any check for consistency, then that
is likely the easiest solution for us currently.  However, it probably means
that EDA tools can't take the [Ramp] data too literally in the context of non-
traditional models.

- Michael: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

New ARs:

Yifan:  Investigate with Arpad's SPICE circuit to see whether characteristics
        of rising and falling edges can help a model maker decide whether
        BIRD220.1 is applicable.

-------------
Next meeting: 24 September 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
